An enterprise may store information about other entities, such as people (e.g., customers, patients, employees, or insurance policy holders) and/or other companies, in order to process transactions during the normal course of business. Moreover, some of the stored information might be considered “personal information,” such as for example, a person's name, home address, email address, telephone number, credit card number, or Social Security number. Note that a person might expect that the enterprise would not let his or her personal information be accessed by anyone who does not need the information in order to process the transaction. As a result, an enterprise will generally attempt to restrict access to personal information to protect the privacy of the entities (e.g., customers) and reduce the likelihood of identity theft and similar abuses.
In addition, certain types of personal information are protected by governmental requirements that dictate how particular items of information must be handled. For example, Personally Identifiable Information (PII) and/or Personal Health Information (PHI) as defined in various US governmental regulations must be protected in accordance with specific sets of rules. Note that other countries or regions (e.g., the European Union or Japan) might have similar laws and/or rules.
In some cases, an enterprise may use one or more automated programs or applications that access information, including personal information, from data stores (e.g., databases). For example, an enterprise might have a billing application that accesses a customer's name and home address from a data store in order to mail a billing statement to the customer's home.
Note that an enterprise might want to use information from a data store, including types of information that may be considered personal, even when the information is not needed to complete an actual transaction with a customer. By way of example, it might be helpful to share such information with a team of system designers who are developing and/or testing a new or updated version of an application.
To avoid disclosing any personal information associated with actual customers, an enterprise could create an entirely fictitious or fictional data store. Such an approach may be impractical, however, when an application needs to be tested with relatively large data stores (e.g., databases that contain information about tens of thousands of entities). Moreover, generating complicated data stores that mimic actual data stores can be a difficult and expensive process. For example, many different data stores—each establishing different relationships between elements within and between those data stores—might need to be created and tested.
As another approach, an actual data store could be manually reviewed to locate data that might be considered personal information and/or such data could be manually deleted or replaced with different information. These actions, however, can be time consuming, error prone, and difficult to administer in a cost effective basis, especially when a substantial number of database elements are involved.